You
can use T-SQL or the visual tools available in SSMS to manage
permissions. Based on the number of available permissions and their
complexity, it is recommended that you use the SSMS tools. The
following sections cover these tools from several different angles and look
at the management of permissions at different levels of the security
model. You learn how to use T-SQL to manage the permissions as well.
Using SSMS to Manage Permissions
The Object Explorer in SSMS
enables you to manage permissions at many different levels of the
permission hierarchy. You can manage permissions at a high level, such
as the entire server, or you can manage permissions at the very lowest
level, including a specific object, such as a table or stored
procedure. The degree of granularity you use for permissions depends on
your security needs. To demonstrate the scope of permissions, let’s
look at managing permissions at several different levels, starting at a
high level and working down to the object level.
Note
There are many different ways
to achieve a security goal in SSMS. For example, you can manage
permissions for a database user from the database or from the user. You
can apply permissions on schema objects for the entire schema or to
individual objects. You should always try to choose the permission
solution that allows you to achieve your security goals with the least
amount of administrative overhead.
Using SSMS to Manage Permissions at the Server Level
Logins can be
granted explicit permissions at the server level. Earlier we looked at
fixed server roles as one means for assigning permissions, but you can
manage individual server-level securables as well. Figure 1 shows the Login Properties window for a login named Chris. You launch this window by right-clicking the login and selecting Properties. Figure 1 shows the Securables page, which allows you to add specific securables to the grid.
Note
You can open a Permissions page like the one shown in Figure 1
from many different places in the Object Explorer. The title of the
dialog box and the content of the grid vary, depending on the object
selected, but the screen is generally the same, no matter where it is
launched. This provides consistency and simplifies the overall
management of permissions.
You can click the Search button shown toward the top of Figure 1 to add objects to the securables grid. When you click this button, the Add Objects window shown in Figure 2
is displayed. This window allows you to choose the types of objects you
want to add. If you select Specific Objects, you are taken directly to
the Select Objects window. If you choose All Objects of the Types, you
are taken to an intermediate screen that allows you to select the type
of objects you want to assign permissions to.
Again, the Add button and
the means for adding objects are fairly consistent for all permissions.
What varies is the object types available for selection. For example,
at the server level, the types of objects available to assign
permissions are scoped at the server level. Figure 3
shows the Select Object Types window displayed when you choose the All
Objects of the Types option at the server level. You can see that the
available objects are all scoped at the server level.
If the endpoints objects are selected, the securables grid is populated with all the available endpoints that have permissions to manage. Figure 4 shows the Login Properties window with the endpoints securables populated. The TSQL Named Pipes
securable is selected, which allows you to specify the explicit
permissions for the securable in the bottom grid. In this example, the
Grant and With Grant check boxes have been selected for the control
permission. This gives the login named Chris the right to control the Named Pipes endpoint and also allows him to grant this control right (because With Grant is selected) to other logins.
The examples we just
walked through are related to the assignment of explicit permission on
a specific instance of a securable. You can also apply server
permissions at a higher level. For example, you might want to specify
permissions for a login to allow that login to control all server
endpoints instead of specific endpoints. You can accomplish this in
several ways. One way to do it is to select the Server
object from the list of object types when adding permissions for a
specific login. Another way is to right-click the server name in the
Object Explorer and select Properties. The Server Properties window
that appears has a Permissions page that lists all the logins for the
server, along with the macro-level permissions scoped for the server. Figure 5 shows the Server Properties window with the login Chris
selected. The explicit permissions listed in this case are at a higher
level and are not just for one instance. The example shown in Figure 5 allows the login Chris to alter any database or any endpoint on the server. This is based on the Grant check boxes selected.
